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METHOD AND APPARATUS FOR PROVIDING EFFICIENT VoIP 
GATEWAY-TO-GATEWAV COMMUNICATION 

BACKGROUND OF THE DISCLOSURE 

1 . Technical Field of the Invention 

This invention generally relates to the field of communication systems and, more 
particularly, to a Voice over Internet Protocol (VoIP) gateway to gateway communication 
system for use in an Internet Protocol (IP) network. 

2. Description of the Background Art 

Voice over Internet Protocol (VoIP) is a technology that allows the transmission of 
voice using an Internet Protocol (IP) network, such as the Internet. For instance, a calling 
party places a call on a telephone set. The telephone set digitizes the voice signal and 
transmits the voice signal to a VoIP gateway servicing the calling party. The VoIP gateway, 
in turn, establishes a call with a VoIP gateway that services the called party. 

Presently the International Telecommunication Union - Telecommunication 
Standardization Sector (ITU-T) Recommendation H.323 specifies the technical 
requirements for the packets transmitted between VoIP gateways. Each packet has a Real- 
time Transport Protocol (RTP) header for carrying real time services such as voice and 
video in a pay load portion of the RTP packet, a payload identifier so that the receiving 
gateway can determine the type of information contained in the packet, and sequence 
numbers and timstamps for identifying the order of the packets. In addition, the RTP 
packet is encapsulated in a User Datagram Protocol (UDP) transport/Internet Protocol (IP) 
layer packet. 

UnforUmately, RTP and UDP overheads are too large. For example, the UDP header 
is 40 bytes and the RTP header is 12 bytes. As conventional methods are used to reduce the 
size of the Internet Protocol (IP) voice payload from 64 kb/s to as low as 4 kb/s, the RTP 
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and UDP comprise a larger portion of the data actually transmitted resulting in inefficiency 
when transporting packets between VoIP gateways. 

SUMMARY OF THE INVENTION 
The invention comprises a system and method for transmitting and receiving 
multiplexed Voice over Internet Protocol (VoIP) traffic. The invention advantageously 
provides efficient gateway-to-gateway communication by reducing overhead where at least 
two conversations are transmitted between the same VoIP gateways. Additionally, signal 
degradation is avoided since there is no transcoding of signals. 

A method of transporting voice traffic from a Voice over Internet Protocol (VoIP) 
gateway, over an Internet Protocol (IP) network, to a destination, according to the present 
invention comprises the steps of: receiving voice traffic at the VoIP gateway; determining 
whether the destination is serviced by a second VoIP gateway; multiplexing the voice traffic 
at the VoIP gateway; and transporting the multiplexed voice traffic to the second VoIP 
gateway utilizing a plurality of transport packets, responsive to an affirmative 
determination that the destination is serviced by the second VoIP gateway. 

An apparatus for transporting voice traffic over an Internet Protocol (IP) network to 
a destination, according to the present invention, comprises: a first Voice over Internet 
Protocol (VoIP) gateway, for receiving voice traffic; the first VoIP gateway determining 
whether said destination is serviced by a second VoIP gateway; the first VoIP gateway 
multiplexing said voice traffic; the first VoIP gateway transporting the multiplexed voice 
traffic to the second VoIP gateway utilizing a plurality of transport packets, responsive to 
an affirmative determination that the destination is serviced by the second VoIP gateway. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The teachings of the present invention can be readily understood by considering the 

following detailed description in conjunction with the accompanying drawings, in which: 

FIG. 1 depicts a high level block diagram of a communications system including the 

present invention; 
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FIG. 2 depicts a high level block diagram of an embodiment of the controller suitable 
for use within a Voice over Internet Protocol (VoIP) gateway; 

FIG. 3 depicts a flow diagram of a mediod for providing VoIP gateway to gateway 
communication over the Internet Protocol (IP) network according to the invention; 

FIG. 4 depicts a diagram of a modified H.323 packet data structure useful in 
understanding the operation of the communications system in FIG. 1 ; 

FIG. 5 depicts a transport packet data structure comprising multiple RTP payloads; 

and 

FIG. 6 depicts a call flow diagram useful in understanding an embodiment of the 
present invention. 

To facilitate understanding, identical reference numerals have been used, where 
possible, to designate identical elements that are common to the figures. 

DETAILED DESCRIPTION 

The invention will be primarily described within the context of a pair of subscribers 
(A and B) communicating via Voice over Internet Protocol (VoIP) utilizing different 
transport mediums, for example Digital Subscriber Line (DSL), Plain Old Telephone Service 
(POTS), cellular and cable modem technologies. It should be noted by those skilled in the 
art that the applicability of the present invention is not limited to this embodiment. 

FIG. 1 depicts a high level block diagram of a communications system including the 
present invention. Specifically, the system of FIG. 1 comprises a first VoIP gateway 122 
which is coupled to a telephone 102 via a transmission medium 1 10 (illustratively, a copper 
pair, coaxial cable, fiber optic cable or the like), a first Voice over Digital Subscriber Service 
Line (VoDSL) Integrated Access Device (IAD) 1 12 via a transmission medium 1 14, a cable 
modem 1 16 via a transmission medium 118, and a first cell site 120 via a transmission 
medium 121. First VoDSL IAD 1 12 is in turn coupled to a terminal 104 (illustratively, a 
telephone, a Personal Computer(PC) or workstation), A terminal 106 is coupled to cable 
modem 1 16. A cellular phone 108 is coupled to first cell site 120 via a radio frequency link. 
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It should be noted that the present invention does not require a specific DSL service 
type, such as Asymmetric Digital Subscriber Line (ADSL), Rate Adaptive DSL (RADSL), 
Single-line DSL (SDSL), Integrated Services Digital Network (IDSL) and the like. 
Therefore, those skilled in the art and informed by the teachings of the present invention 
will be able to readily adapt any appropriate DSL service type to the present invention. 

The first VoIP gateway 122 is coupled to an Internet Protocol (IP) network 126. 
Also coupled to IP network 126 is a second VoIP gateway 128 and, optionally, a 
gatekeeper 124. The gatekeeper has a database (not shown) for storing IP addresses which 
correspond to telephone numbers. Each VoIP gateway 122, 128 has a plurality of User 
Datagram Protocol (UDP) ports (not shown) as well as a respective VoIP gateway 
controller 122C and 128C respectively. Second VoIP gateway 128 is coupled to a telephone 
132 via a transmission medium 130, a second Voice over Digital Subscriber Service Line 
(VoDSL) Integrated Access Device (IAD) 140 via a transmission medium 142, a second 
cable modem 144 via a transmission medium 146, and a second cell site 148 via a 
transmission medium 149. Second VoDSL IAD 140 is in turn coupled to a terminal 134. In 
addition, a terminal 136 is coupled to second cable modem 144, and cellular phone 138 is 
coupled to second cell site 148 via a radio frequency link. 

It should be noted that the operation of the first VoIP gateway 122 is similar to the 
operation of the second VoIP gateway 128. As such, only differences between the first 
VoIP gateway 122 and second VoIP gateway will be described in more detail. 

As a call arrives at the first VoIP gateway 122, for example from a DSL subscriber, 
first VoIP gateway 122 compares the phone number of the called party to a database which 
has a corresponding IP address for a VoIP gateway (e.g. VoIP gateway 128) that serves the 
called party. After a determination is made that the second VoIP gateway exists and is 
compatible, via signaling messages communicated between the respective gateways another 
determination is made by the first VoIP gateway 122 whether traffic is being presently 
provided to the second VoIP gateway 128. If traffic is currently being provided to the 
second VoIP gateway 128, voice traffic from the recent call is encapsulated with a modified 
Real-time Transport Protocol (RTP) which will be discussed more fully in FIG. 3. The 
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modified RTP packet is then multiplexed with other voice traffic going to the second VoIP 
gateway 128 and encapsulated in a User Datagram Protocol (UDP) transport packet. The 
UDP transport packet with the encapsulated modified muhiplexed RTP packets are 
communicated to the second VoIP gateway 128 via a logical link. If traffic is not currently 
being provided to the second VoIP gateway 128, the modified RTP packet is encapsulated 
in a user data protocol transport packet. Multiplexing will then occur when traffic from 
other callers is being routed to the second VoIP gateway 128. 

It should be noted that each modified RTP packet includes an identifier for each 
caller. This way when a call becomes inactive for particular callers and called parties, the 
logical link is not broken but remains up until all calls become inactive. 

At the second VoIP gateway 128, the UDP/IP packet is received and the modified 
RTP packets are demultiplexed and decoded. Each call is then routed to the appropriate 
destination. 

In another embodiment of the invention, the gatekeeper 124 can be used to look up 
IP addresses for corresponding telephone numbers. 

It should be noted by those skilled in the art that although the invention is described 
in the context of a call being established in one direction, the call can be established in either 
direction and communication between the respective gateways 122 and 128 can occur 
simultaneously according to the present invention. 

FIG. 2 depicts a high level block diagram of an embodiment of the controller suitable 
for use within a Voice over Internet Protocol (VoIP) gateway. Specifically, FIG. 2 depicts 
a high level block diagram of a VoIP gateway 122 suitable for use in the communication 
system 100 of FIG. 1. The VoIP gateway controller 122C comprises a microprocessor 220 
as well as memory 230 for storing programs 250 such as VoIP processing method 300 
which will be described more fully below in a discussion of FIG. 3. The microprocessor 
220 cooperates with conventional support circuitry 240 such as power supplies, clock 
circuits, cache memory and the like as well as circuits that assist in executing the software 
methods of the present invention. As such, it is contemplated that some of the process 
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steps discussed herein as software processes may be implemented with hardware, for 
example, a circuitry that cooperates with the microprocessor 220 to form various steps. 

The VoIP gateway controller 122C also comprises input/output circuitry 210 that 
forms an interface between the microprocessor 220, the IP network 126, telephone 102, 
VoDSL IAD 1 12, cable RG 1 16, cell site 120, and other VoIP circuitry (not shown). 

Although the VoIP controller 122C is depicted as a general purpose computer that is 
programmed to perform VoIP control and processing functions in accordance with the 
present invention, the invention can be implemented in hardware, in software, or a 
combination of hardware and software. As such, the processing steps described above with 
respect to the various figures are intended to be broadly interpreted as being equivalently 
performed by software, hardware, or a combination thereof 

It will be appreciated by those skilled in the art that the VoIP controller 122C 
provides sufficient computer functionality to implement the invention as described above. 

FIG. 3 depicts a flow diagram of a method for providing VoIP gateway to gateway 
communication according to the invention. The method 300 of FIG. 3 may be stored in the 
VoIP controller 122C in , for example, memory 230 within the portion used for storage of 
various programs 250. 

The method 300 is initiated at step 302 and proceeds to step 304, where the first 
VoIP gateway 122 receives a request from a source to connect to a respective destination. It 
should be noted that the first VoIP gateway may also receive multiple requests from 
multiple sources for connections to multiple destinations. 

At step 306 a determination is made as to whether the requested destination is 
served by a corresponding VoIP gateway (e.g. VoIP gateway 128) via signaling messages 
between the respective VoIP gateways. Box 308 provides exemplary means of determining 
whether such a corresponding VoIP gateway exists. Specifically, the telephone number of 
the called party can be compared to a database in the first VoIP gateway 122 which 
contains a list of telephone numbers and respective IP addresses of VoIP gateways which 
serve those telephone numbers. Alternatively, a gatekeeper 124 including such data can be 
used in order to conserve memory in the VoIP gateways. The gatekeeper 124 will look up a 
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respective IP address for the called party. In addition, any type of memory storage device 
can be used in place of a VoIP gateway or gatekeeper to store telephone numbers and 
corresponding IP addresses. The method 300 then proceeds to step 310. 

At step 310 a query is made as to whether a second VoIP gateway 128 found at 
step 306 is compatible with the first VoIP gateway 122. Compatibility is defined as being 
able to demultiplex and decode the data structure used in the present invention. If the query 
at step 3 10 is answered negatively, the method 300 proceeds to step 3 12 where the call is 
routed and transmitted in a conventional manner. That is, if a second gateway does not 
exist, or an existing second gateway is not compatible, then conventional call routing is 
employed. The method then proceeds to step 314 where it exits. 

If the query at step 310 is answered affirmatively, the method proceeds to step 316 
where a query is made as to whether first VoIP gateway 122 presently provides voice 
traffic to second VoIP gateway 128. If the query at step 316 is answered affirmatively, the 
method then proceeds to step 320. If the query at step 3 16 is answered negatively, the 
method then proceeds to step 318 where a logical link is established between first VoIP 
gateway 122 and second VoIP gateway 128 with a port number and call identifier. The 
matter 300 then proceeds to step 320. 

At step 320 the voice traffic is appended with a modified Real-time transport 
protocol header according to the present invention. In communicating to each other, each 
respective gateway communicates a UDP port number to the other gateway in which to 
access the gateway and a call identifier in which to differentiate the respective callers. For 
instance, the first VoIP gateway 122 may communicate that a transmission is occurring on 
port number 2 and the calling party is identified as caller number 7. The second gateway 
128 will respond with a port number (i.e., port number 7) and identify the called party as 
number 5. 

At step 322, the new call is multiplexed with the other, if any, ongoing 
conversations onto a UDP/IP packet. It should be noted that the addition of the newly 
multiplexed voice traffic is constrained by Quality of Service issues such as the number of 
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modified RTP packets which can be muhiplexed due to latency, delay and time stamp 
constraints, etc. 

At step 324, a query is made as to whether any additional modified RTP packets 
from new callers need to be multiplexed. If the query at step 326 is answered affirmatively, 
the method proceeds to step 304. If the query at step 324 is answered negatively, the 
method proceeds to step 326. 

At step 326 a query is made as to whether all callers are still active. If the query at 
step 326 is answered affirmatively, the method proceeds to step 324. If the query at step 
326 is answered negatively, the method proceeds to step 330 where any inactive callers are 
dropped and the inactive caller's respective call identifier is released and made available for 
assigrmient to future callers. 

At step 330 a query is made as to whether only one caller is active. If the query is 
answered negatively, the method proceeds to step 324. If the query at step 330 is answered 
affirmatively, the method proceeds to step 332 where the logical link is broken and the port 
is cleared. The method then proceeds to step 334 where it ends. 

FIG. 4 depicts a diagram of a modified H.323 packet data structure useftil in 
understanding the operation of the communications system in FIG. 1. Specifically, FIG. 4 
shows the packet data structure of a modified Real-time Transport Protocol (RTP) packet, 
according to the present invention, that may be used to transport voice and other data 
between VoIP gateways, such as first VoIP gateway 122 and second VoIP gateway 128. 
Any differences between the standard RTP packet structure and the modified RTP packet 
structure of FIG. 4 comprise data structure modifications according to the present 
invention. The standard or unmodified RTP packet data structure is more thoroughly 
described in the International Telecommunication Union - Telecommunication 
Standardizafion Sector (ITU-T) Recommendation H.323, which is incorporated herein by 
reference in its entirety. 

The data structure of modified RTP packet 400 comprises a conventional RTP 
header 402 and the following additional fields:; a Call Identifier field (CI) 404 for identifying 
a caller between a telephone set and a respective gateway; a Length Indicator field (LI) 406 
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for identifying the size of the payload; and a Header Error Check (HEC) field 408 for 
identifying errors in the Call Identifier field 404 and the Length Indicator field406. It 
should be noted by those skilled in the art that HEC field 408 can be modified to identify 
errors in additional fields. The size of Call Identifier field 406 is one byte, but may be larger 
depending on the number of terminals or telephone sets coupled to a respective gateway. 
The HEC field 408 is preferably one byte. 

In another embodiment of the modified RTP packet data structure of the present 
invention, Header Check field 406 allows one bit error correction due to errors induced by 
noise, interference and other environmental conditions. This error correcting capability 
improves Quality of Service (QoS) for the traffic represented by the packets transmitted 
between the VoIP gateways. 

The above described packet structure may be transported as payload within a 
transport data packet structure as depicted in FIG. 5. Specifically FIG. 5 depicts a User 
Datagram Protocol (UDP)Antemet Protocol (IP) transport layer packet comprising multiple 
RTPmodified packets and payloads. The UDP/IP packet data structure is more thoroughly 
described in the International Telecommunication Union - Telecommunication 
Standardization Sector (ITU-T) Recommendation H.323. 

A UDP/IP packet 500, according to the invention, comprises muhiple modified RTP 
fields as illustrated in FIG. 5 where RTPl packet504 and payload 506, RTP2 packet 508 
and payload 510, up to RTPN packet 512 and payload 514 are independent fi-om each 
other and are encapsulated in a common UDPAP packet 500 having a UDP header 502. 

FIG. 6 depicts a call flow diagram useful in understanding an embodiment of the 
present invention. In the call flow diagram of FIG. 6, the signaling for the call setup and 
disconnect among first VoIP gateway 122, gatekeeper 124 and second VoIP gateway 128 is 
defmed in the International Telecommunication Union - Telecommunication 
Standardization Sector (ITU-T) Recommendation H.225, which is incorporated herein by 
reference in its entirety. Control operations as well as capabilities exchange is defined in the 
International Telecommunication Union - Telecommunication Standardization Sector (ITU- 
T) Recommendation H.245, which is incorporated herein by reference in its entirety. 
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H.225 signaling begins with party A initiating an Internet call by picking up 
telephone 102 and dialing party B's telephone number which is also known as an E. 164 
address. At step 602 the first VoIP gateway 122 communicates a Location Request (LRQ) 
message to gatekeeper 124 seeking the transport address of the second VoIP gateway 128 
serving party B's telephone number. Gatekeeper 124 retrieves a table which contains 
transport addresses for corresponding telephone numbers. 

At step 604, gatekeeper 124 communicates a Location Confumation (LCF) message 
to first VoIP 122 indicating that a transport address for second VoIP 128 was found. The 
LCF message may also contain the transport address of the second VoIP gateway 128. 

Although not shown, gatekeeper 124 can also provide a Location Reject (LRJ) 
message indicating that for the telephone number given a corresponding transport address 
for a second VoIP 128 that serves party B can not be found. A failure to detect a 
corresponding phone number phone number can result, for example, from party A dialing 
the wrong telephone number, the database for storing telephone numbers and corresponding 
transport addresses has not been updated or the VoIP gateway serving party B is not 
recognized by the gatekeeper 124. 

At step 606, first VoIP gateway 122 communicates an Admissions Request (ARQ) 
message to gatekeeper 124 providing admissions control and bandwidth management 
functions. For instance, first VoIP gateway 122 may specify the requested call's bandwidth 
to gatekeeper 124. 

Gatekeeper 124 responds at step 608 by communicating an Admissions Confirm 
(ACF) message to the first VoIP gateway 122 indicating that the first VoIP's 122 request 
for bandwidth has been received and the parameters for the call accepted. 

At step 610 first VoIP gateway 122 communicates a Setup message to second VoIP 
gateway 128 using the transport address. Responsively, at step 612, second VoIP gateway 
128 communicates a Call Proceeding message to first VoIP gateway 122 indicating that the 
Setup message is in process. 
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At step 614, if VoIP gateway 128 would like to receive the call from VoIP gateway 
122, VoIP gateway 128 communicates an ARQ message to gatekeeper 124 providing 
-admissions control and bandwidth management functions. 

In response to VoIP gateway's 128 ARQ message, gatekeeper 124 communicates an 
ACF message at step 616 indicating that VoIP gateway's 128 ARQ message has been 
received and the parameters for the call accepted. 

At step 618, second VoIP gateway 128 communicates an Alerting message to first 
VoIP gateway 122 indicating that party B's telephone 132 is ringing. When party B picks 
up telephone 132 at step 420, second VoIP gateway communicates a Connect message to 
first VoIP gateway 122 indicating that an H.225 call signaling channel has been established. 

The call flow diagram of FIG. 6 enters the capabilities exchange stage at step 622 
where first VoIP gateway 122 and second VoIP gateway 128 communicate Capabilities 
Exchange messages with each other. During this process the respective VoIP gateways make 
known to each other their capability to receive and decode various signals. For example, it is 
not necessary that a VoIP gateway understand all of the respective VoIP gateway's 
capabilities. Capabilities not used or understood are simply disregarded by the respective 
VoIP gateway. 

At step 624 first gateway 122 communicates an Open Logical Channel message to 
second VoIP gateway 128 indicating that a Logical Channel should be opened. The Open 
Channel message fiilly describes the content of the Logical Channel, including media type, 
algorithm in use, any options and all other information needed for second VoIP gateway 128 
to interpret the content of the Logical Channel for example. Illustratively, the Open Logical 
Charmel message is depicted as containing port number one as a means for which second 
VoIP gateway 128 can communicate UDP/IP packets to the first VoIP gateway 122 for the 
second caller. 

Second VoIP gateway 128 responds at step 626 with an Open Logical Channel 
Acknowledgement message indicating that first VoIP gateway 122 can communicate 
UDP/IP packets to second VoIP gateway 128 via port number two for the second caller, for 
example. 
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The call flow diagram of FIG. 6 enters the call signaling stage at step 628 where first 
VoIP gateway 122 communicates a Disconnect message to second VoIP gateway 128 
indicating that party A has terminated the call. 

In response to the termination of the call by party A, at step 630, second VoIP 
gateway 128 communicates a Release message to first VoIP gateway 122 indicating that the 
prior message has been received and party B has released the call. 

The call flow diagram of FIG. 6 enters the control stage at step 632 where first 
gateway 122 communicates a Close Logical Channel message to second VoIP 128 indicating 
that the call for a specified Call Identifier 406 should be terminated. For example, if there 
was only one call going from the first VoIP gateway 122 to second VoIP gateway 128 on 
port number one for a caller with a Call Identifier 404 of two, closing the Logical Channel 
will clear the call with the given Call Identifier 404 of two and clears the UDP port. 
However, if more than one call was taking place between first VoIP gateway 122 and 
second VoIP gateway 128, closing the Logical Channel will only clear the call for a specific 
Call Identifier 406. The UDP port remains intact and other calls remain in progress until the 
specific user terminates the call. 

At step 634, second VoIP gateway 128 communicates a Close Logical Channel 
Acknowledgement message to first VoIP gateway 122 indicating that the called party has 
terminated their portion of the call, and the Logical Channel going from second VoIP 
gateway 128 to first VoIP gateway 122 should be closed for the respective Call 
Idenfifier404. 

The above-described invention advantageously provides a means of communicating 
voice traffic between VoIP gateways in composite call formation form. Moreover, the 
invention advantageously does not require a conversion of the voice traffic payloads into a 
different format between gateways. The voice traffic payloads remain intact. Thus avoiding 
signal degradation and delay in converting payloads into different formats. In this manner, 
the invention provides a substantial improvement over prior art VoIP gateway-to-gateway 
communication; thereby providing a signal with reduced overhead where at least two 
conversations are transmitted between VoIP gateways. 
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It is noted that the number of modified RTP packets included within a UDP/IP 
packet is limited by Quality of Service issues. For instance, multiplexing a large number of 
modified RTP packets will increase system latency and delay due to increased buffering 
requirements. 

Although various embodiments which incorporate the teachings of the present 
invention have been shown and described in detail herein, those skilled in the art can readily 
devise many other varied embodiments that still incorporate these teachings. 
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